In the IBM Technical Disclosure Bulletin publication article entitled "Designing Flexibility into Hardwired Logic" (TDB v37 n3 03-94 p321-324) the authors, M A Check, A Lo, and J R Smith, disclosed the use of opcode compare logic for adding flexibility to a logic design which contains hardwired logic. The primary reason for using hardwired logic is to maximize performance, but this has the disadvantage of being rigid, and the hardware must be replaced whenever there is a design change. In some situations changes occur frequently, and it becomes very costly for the manufacturer to replace hardware with each change. This article outlines a solution to this problem and shows how to design logic that is hardwired for performance and flexible to change. The technique is to design the hardwired logic and then implement some programmable logic on the side for use whenever the design must change. Design changes are performed by switching out a portion of the hardwired logic and replacing it with programmable logic. Since most changes are small, the system remains mostly hardwired and the impact on performance is usually negligible. As an application of this design technique, the focus will be on the instruction decode logic of a central processor. It is common for architecture changes to occur after the hardware has been released to the field. By making an instruction decoder which is partially programmable, the manufacturer can save a significant amount of money on the cost of doing field upgrades for changes in the instruction set. A second advantage of using a partially programmable decoder is its power as a debugging tool. Opcode Compare is a tool for debugging problems in the central processor (CP). It was described in the article as consisting of a set of programmable opcode registers, each with a control word. The user has the ability to control the way instructions decode and execute by writing values into the opcode and control registers. To modify the behavior of an instruction, the opcode is written to one of the opcode registers and a control word is also written. Each time that opcode decodes, its hardwired instruction characteristic is modified according to the value of the control word. Actions that can be controlled include disabling multiple instructions per cycle decode, disabling decode until all prior instructions complete (disable overlap), serialization and switching execution between hardware and microcode or mullicode elements.
Every computer system must deal with architectural changes. A common occurrence is the announcement of new instructions, where a previously reserved invalid opcode becomes valid. In cases where the hardware is in the field, the manufacturer usually offers to upgrade the customer's system to meet the new architecture. By using the design techniques discussed below, the manufacturer can minimize its hardware replacement cost. To do this, the manufacturer reprograms the hardware for the instruction decoder to mark the new opcode valid and dispatch it to an appropriate execution unit. Depending upon available space on chip, there are two choices for implementing this. If space is not a constraint, then every reserved invalid opcode is mapped into a unique address in an array. The array contains as instruction characteristic for each opcode. To change an opcode from invalid to valid, a new instruction characteristic is written to the array. Then, whenever this opcode is encountered, it will decode and execute as specified by the characteristic entered in the array. If space is a constraint, then a limit is placed on the total number of opcodes that can be transformed from invalid to valid. The opcodes to be transformed are entered into a set of registers similar to the ones used for Opcode Compare. Each compare register points to an address in the array. As above, to change an opcode from invalid to valid, a new instruction characteristic is written into the array and will be used whenever this opcode decodes. In both implementations the output of the hardwired decoder is blocked one cycle to give the array a chance to produce a new characteristic for this instruction. The article illustrates how to implement this type of flexibility.
However, in so far as we have been able to determine, until now Opcode Compare logic is commonly implemented in the instruction unit (I-unit) where it has the disadvantage where it can adversely affect cycle time. We have found no processor which has implemented Opcode Compare logic in the execution unit (E-unit), and we with this application report that we have found that there are advantages in doing so, as we will describe, specifically with respect to our processor E-Unit to I-Unit interface mechanism for instruction modification with these features below.